Lecture 13 — exploring the modern DevOps toolbox, deep diving into containerization and orchestration, configuration management, and a real-world enterprise CI/CD adoption story at IBM.
"A fool with a tool is still a fool. Process and culture must come first; the tool just automates the culture." — Grady Booch
A tool with 80% of the features that integrates seamlessly with your existing stack is better than a 100% perfect tool that lives in a silo.
Every tool you select must have a robust REST or GraphQL API. If you can't automate interacting with the tool, it's not a DevOps tool.
Choose tools with large ecosystems (like Kubernetes or Terraform). You'll find answers faster on StackOverflow and hire engineers more easily.
| Feature | Virtual Machines (VMware, EC2) | Containers (Docker) |
|---|---|---|
| Architecture | Hardware-level virtualization via Hypervisor | OS-level virtualization (shares host kernel) |
| Guest OS | Each VM includes a full, heavy Operating System | No Guest OS; only app and dependencies |
| Startup Time | Minutes (booting the entire OS) | Milliseconds to seconds |
| Size / Weight | Gigabytes (GBs) | Megabytes (MBs) |
| Resource Usage | Heavy overhead; pre-allocated resources | Lightweight; uses only what it needs |
The takeaway: Containers solved the "it works on my machine" problem by packaging the application and all its dependencies into a single, immutable artifact that runs exactly the same everywhere.
A text file containing the step-by-step instructions (commands) to build a Docker Image. (e.g., FROM node:18, COPY . /app, RUN npm install).
The read-only template created by building the Dockerfile. It contains your app, runtime, and libraries. Images are stored in a Registry (e.g., Docker Hub).
A running instance of an Image. It has a writable layer on top. You can run hundreds of identical containers from one single image.
Docker is great for running 1 or 5 containers on a single laptop or server. But what happens when you have a microservices architecture with 5,000 containers running across 200 servers?
kubectl)While Terraform provisions the cloud infrastructure (the servers), Configuration Management tools install and configure the software inside those servers.
| Feature | Puppet | Ansible |
|---|---|---|
| Architecture | Agent-based (Puppet agent runs on every node) | Agentless (connects via standard SSH) |
| Language | Puppet DSL (Ruby-like, declarative) | YAML (Playbooks, procedural/declarative mix) |
| Push vs Pull | Pull (Agents pull configs from Master) | Push (Master pushes commands to nodes) |
| Learning Curve | Steep (requires learning Puppet DSL) | Very Low (simple YAML, Python-based) |
| Best For | Large, static, complex enterprise environments | Fast-moving, dynamic environments, CI/CD |
Why it's powerful: Idempotency. You can run this playbook 100 times. If Nginx is already installed and running, Ansible does nothing. It only makes changes when the actual state differs from the desired state.
IBM needed to build and manage a massive Kubernetes-as-a-Service platform. The engineering team was globally distributed. They faced a critical challenge: How do you ship code safely when hundreds of engineers are committing to the same monolithic codebase every day?
Deployment time shrank drastically, allowing multiple deployments per day per microservice.
Automated regression testing caught defects before they ever reached production.
Developers no longer waited for "Ops" to deploy; the pipeline handled the heavy lifting.
The ultimate lesson from IBM: Tools like Kubernetes and Jenkins were essential, but the real transformation was cultural — mandating test-driven development and forcing small, incremental commits instead of massive monthly releases.
Hands-on: Setting up CI/CD Pipelines; Hands-on: Infrastructure Automation in practice.
We will be looking at terminal workflows for Git, GitHub Actions, and basic Ansible. Familiarize yourself with YAML syntax.